home *** CD-ROM | disk | FTP | other *** search
- WAD Auxiliary Resource Manipulator
- Version 1.5 of November 1995 by Robert Fenske, Jr (rfenske@swri.edu)
- Ported to OS/2 by Mark K. Mathews (mmathews@genesis.nred.ma.us)
-
- Summary of features
- -------------------
-
- o The fastest NODES/SSECTORS/SEGS builder on the planet
- o Fastest BLOCKMAP builder on the planet
- o Fully automatic REJECT resource builder
- o Manual REJECT special effect manipulation
- o Works with all levels in DOOM I, DOOM II, HERETIC, and
- HEXEN WAD files
- o Has various utility function options, including
- merging WADs and levels
- extracting resources
- substituting resources
- randoming things
- rename resources
- packing/unpacking WADs
- o Full source code
- o Compiles and runs under these operating systems:
- MS-DOS, OS/2, SunOS 4.1.x, Solaris 2.x,
- Linux, FreeBSD, HP-UX, VMS, Windows/NT
-
- General description
- -------------------
-
- This is release 1.5 of my WAD Auxiliary Resource Manipulator, or
- WARM and is an update of my previous 1.4 release of May 1995. There are
- quite a number of changes between these releases (see below).
- This package consists of the following fifteen files:
- WARM15.TXT This text file
- DMGLOBAL.I The include file
- WARM.C \
- WADIO.C \
- NODES.C WARM C sources
- BLOCKMAP.C /
- REJECT.C /
- WARMDOS.EXE MS-DOS executable
- WARMOS2.EXE OS/2 2.1 executable
- MAKEFILE.DOS MS-DOS GCC makefile
- MAKEFILE.OS2 OS/2 2.1 C/Set++ makefile
- MAKEFILE.UNX various Unix flavors makefile
- MAKEFILE.COM VMS build script
- WARMOS2.DEF OS/2 2.1 auxiliary file
- EMU387 ix86 floating point emulation library
-
- WARM's main purpose is to build the NODES, SSECTORS, SEGS, BLOCKMAP,
- and REJECT resources from the basic resources that compose a level.
- Executing the program with no command line arguments will display help
- regarding the command line. Note that there are several optional functions
- available that are unrelated to the reject, nodes, or blockmap creation.
- Hopefully most have an obvious function, but I'm not going to bother to
- exlain any of them. These functions are in this program because I did not
- want to mess with more than one program to get all the functionality I wanted.
- Note that some of the functions (dmit and rand) are not fully implemented
- with respect to HERETIC and HEXEN.
- To use this program under MS-DOS on a computer without a math
- coprocessor requires using the EMU387 floating point math emulation library.
- The environment variable GO32 must be set as "SET GO32=emu <dir>\EMU387"
- where <dir> is the directory in which you have the EMU387 file located.
- The CR/LF pairs in the source code should (must) be converted to LF
- before building WARM on a Unix system. Porting this code to any system I
- haven't already tried should be straightforward. If the target system is
- big-endian, the BIG_ENDIAN define will have to be modified appropriately
- in WADIO.C.
- Any comments, etc about WARM can be directed to rfenske@swri.edu. If
- you do find any WAD file that WARM does not process correctly, please let
- me know about it.
-
- Acknowledgements
- ----------------
-
- Mark Mathews (mmathews@genesis.nred.ma.us)
- Ported the code to OS/2 and performed extensive testing for the
- 1.1 release and prodded me enough to make me finish it.
-
- Matt Fell (MSFell@aol.com)
- His DOOM Specs provided the BLOCKMAP generation optimizations.
-
- Jason Hoffoss (hoffo002@gold.tc.unm.edu)
- The author of DMAPEDIT came up with the packed BLOCKMAP idea.
-
- Bernd Kreimeier (Bernd.Kreimeier@nero.uni-bonn.de)
- Came up with the idea of not creating segs (during node generation)
- for those lines that do not affect the display in any way.
-
- BSP Generation Smarts
- ---------------------
-
- Some lines in a level do not affect the display in any way; these
- lines are those that have no floor nor ceiling changes on either side of them
- and do not have a texture on them. So visually, you can not tell there is
- a line present while playing the game. Thus there is no reason for these
- lines to be considered during node generation. Doing this will create fewer
- NODES, SSECTORS, and SEGS (thus a smaller WAD). There is an option to disable
- this feature since some special effects require that these non-visual lines be
- present in the SEGS list.
- There are two options that can be given to the node builder, the
- "a" option and the "u" option. The "a" option stands for "all SEGS" and
- the "u" option stands for "unique sector". The "a" option controls the
- processing described in the preceeding paragraph. This option usually must
- be present to make special effects like transparent platforms, lifts, etc
- work. This is because all the SEGS must be present in the SEGS list to
- properly fool the DOOM engine into producing the intended display. The "u"
- option controls whether SSECTORS can be created from more than one sector
- (i.e. from SEGS attached to different SECTORS). Normally SSECTORS are only
- created from SEGS from the same sector and so this option is on by default
- (and in rare cases must be on). Currently, the only time that I know of
- that this option needs to be disabled ("!u") is for transparent doors.
-
- HEXEN BSP Requirements
- ----------------------
-
- HEXEN WAD files can contain extended objects called polyobjects.
- These objects, such as doors that open away from the player require that
- the area containing the polyobjects not be split by any partition line
- created during the BSP generation. WARM currently has no mechanism to
- recognize these objects and build the BSP tree around them. If a WAD doesn't
- work, try building the BSP tree with the -n=a option. If it still doesn't
- work, then you'll have to change the WAD.
-
- Packed Level Data
- -----------------
-
- The resource data that forms a typical level can have a significant
- amount of redundant and unused data. The unused data consist of unused
- SIDEDEFS, VERTEXES, and SECTORS that are not referenced by any of the other
- resources and do not contribute to the level that a player sees. Unused
- data is more prevalent in older WADs; most WAD editors now automatically
- remove unused data before the level data is saved. WARM currently does not
- attempt to remove unused level data. The redundant data consists of redundant
- VERTEXES and SIDEDEFS entries. Removing redundant SIDEDEFS entries can
- significantly reduce the size of the level data. The drawback to removing
- duplicate SIDEDEFS is that it can make further editing of the level difficult,
- especially if LINEDEFS and/or SIDEDEFS have to be deleted. Thus any packed
- level should be unpacked if further major editing is required. Lastly, the
- level's BLOCKMAP is packed (see below).
-
- Packed BLOCKMAP
- ---------------
-
- Each block in the BLOCKMAP represents a 128x128 region of the map
- area. Many of these regions will be empty, i.e. no LINEDEFS exist in these
- regions. A normal BLOCKMAP will have a separate entry for each of these empty
- regions. However, doing so is unnecessary. A single entry in the BLOCKMAP
- can represent all of the empty blocks. Having such a single entry can
- typically reduce the size of the BLOCKMAP by 1/3.
-
- REJECT generation algorithm
- ---------------------------
-
- Since I have not seen any other program that does fully automatic
- REJECT generation, I give an explanation of what the builder does in the
- following paragraphs.
- The algorithm for generating the REJECT resource is given in the source
- code. Basically, it is built from strictly line of sight determinations
- between all sector pairs. For each sector pair, a check is made as to whether
- any one-sided lines block the view of a chosen two-sided line from each sector.
- I.e., if one-sided lines block the views of all two-sided lines of one sector
- from all the two-sided lines of the other sector, then the sector pair is
- deemed not in sight of each other. Otherwise, the sector pair can see each
- other (obviously). However, the method used is not perfect and will not catch
- all instances of line-of-sight.
- For each pair of test points, all potentially blocking one-sided lines
- must be checked. To avoid having to check all the one-sided lines of each
- level, the BLOCKMAP is used to greatly limit the search. Since the BLOCKMAP
- is a record of which lines are in each 128x128 block of the map, and since it
- is fairly easy to compute which blocks are between a pair of test points, the
- BLOCKMAP provides a ready list of only those one-sided lines that are
- potentially in the way of line of sight. Even with this method, the process
- is still computationally expensive; for large levels the REJECT computation
- takes far longer than the nodes generation. The program does have an option
- to produce just a zeroed REJECT resource, so the possibly lengthy computation
- time can be avoided.
-
- Version History
- ---------------
-
- 1.5 November 1995 o Fourth released version
- o Added HEXEN support
- o Significantly faster node generator
- o Fixed problem with directory function
- o Fixed problem with rename function (couldn't rename
- more than one resource at a time)
- o Fixed problem with extract function
- o Fixed -map## option (broken in v1.4)
- o Fixed problem with merge function
-
- 1.4 May 1995 o Third released version
- o Fixed split SEGS offset problem in node generator
- o Removed redundant vertex creation in node generator
- o Optimized node partition line computation so node
- generator is now faster
- o Node generator now ignores certain lines when
- creating node tree; added option list to -n to
- enable/disable this action
- o Improvements to the emstat() routine
- o Added negation ability and sector # wildcarding in
- reject exception specification; removed -x option
- and moved exception list to -r
- o Added pack and unpack functions
- o Better command line help
- o Added quiet output option
-
- 1.3 April 1995 o Second released version
- o Implemented packed blockmap
- o Added unique sector method to node generator
- o Reject generator is faster
- o Improvements to the dmit() routine
- o Improvements to the emstat() routine
- o Added rename function
- o Fixed memory usage bug in node generator (only
- affected Linux executable)
- o Tested under FreeBSD, HP-UX, VMS, and Windows/NT
-
- 1.2 February 1995 o Never released
- o Experimental optimizations that didn't really speed
- anything up
-
- 1.1 January 1995 o First released version, compiled for MS-DOS, OS/2,
- SunOS, Solaris, Linux
- o Fixed obscure bugs in the nodes, blockmap, and reject
- generation routines
- o Added Deathmatch v2.0 option to dmit() routine
-
- 1.0 August 1994 o Never released, update of original VNB program
- o Compiled for MS-DOS and SunOS
- o Includes automatic reject builder
-